• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    computing performance and power management with firmware performance data structure the present invention relates to a ppm interface to a computing platform that can be provided with a functionality to facilitate, for one through the ppm interface, firmware performance data, in some modes.
    公开号:BR112014012398B1
    申请号:R112014012398-5
    申请日:2012-11-21
    公开日:2021-06-15
    发明作者:Michael Rothman；Robert Gough；Mark Doran
    申请人:Intel Corporation；Michael Rothman；Robert Gough；Mark Doran；
    IPC主号:
    专利说明:

    [0001] This application claims the benefit and incorporates by reference herein Provisional Patent Application Number 61/563,030, filed November 22, 2011. BACKGROUND
    [0002] The present invention relates generally to a platform performance management interface. Specifically, it is concerned with providing a firmware performance data table (FPDT) structure through a power and performance management interface on a computing platform. BRIEF DESCRIPTION OF THE DRAWINGS
    [0003] The embodiments of the invention are illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which like reference numerals refer to like elements.
    [0004] Figure 1 is a block diagram of a computing platform with FPDT support provided through a PPM interface according to some modalities.
    [0005] Figure 2 is a diagram that shows an abstract representation of a PPM interface implemented in a platform according to some modalities.
    [0006] Figure 3 is a general routine to track FPDT services through a PPM interface according to some modalities.
    [0007] Figure 4 is a diagram that shows a root pointer to a table structure in an ACPI interface according to some modalities.
    [0008] Figure 5 is a diagram that shows a description table structure for an ACPI interface according to some modalities.
    [0009] Figure 6 is a table showing a Firmware Performance Data Table (FPDT) format according to some modalities.
    [00010] Figure 7 is a table showing a performance recording structure according to some modalities.
    [00011] Figure 8 is a table showing performance recording types according to some modalities.
    [00012] Figure 9 is a table showing a type of runtime performance recording according to some modalities.
    [00013] Figure 10 is a table showing an S3 performance table pointer recording according to some modalities.
    [00014] Figure 11 is a table showing an S4 performance table pointer recording according to some modalities.
    [00015] Figure 12 is a table showing an S3 performance table header according to some modalities.
    [00016] Figure 13 is a table showing a basic S3 restart performance recording according to some modalities.
    [00017] Figure 14 is a table showing a basic S3 suspension performance recording according to some modalities.
    [00018] Figure 15 is a table showing a basic firmware boot performance table header according to some modalities.
    [00019] Figure 16 is a table showing a basic firmware boot performance data recording structure according to some modalities. DETAILED DESCRIPTION
    [00020] Figure 1 is a diagram of a portion of a computing platform 100 with a performance and power management (PPM) interface that facilitates tracking of firmware performance data (FPD) according to some modalities. The computing platform, as generally illustrated in the figure, is intended to represent a variety of different types of computing platform including but not limited to servers, desktop PCs, netbooks, ultra-books, tablets, smartphones, and the like. For simplicity and ease of understanding, details and/or components, not relevant to this description, for some platform modalities will be omitted.
    [00021] As used herein, the term "PPM" means performance and energy management and refers to any interface suitable for allowing operating systems, as well as applications through their operating systems, to control, monitor, maintain , etc., the hardware components within a platform, as long as the platform and OS at least with respect to one relevant characteristic, conform to the PPM interface. An example of a PPM is the Advanced Configuration and Power Interface (ACPI).
    [00022] FPD tracking, in some implementations, refers to measuring or identifying and retaining, at least to some degree, the time taken by a platform to perform various firmware boot and sleep processes. A firmware performance data table (FPDT) structure implemented through a PPM interface allows a platform to expose firmware performance data such as boot process times. This allows the platform, as well as the OS, to access the data. Platform and/or component manufacturers may use this information, for example, to verify (and market) their "faster" boot cycles. In some embodiments, an FPD system can measure and provide data about basic platform boot (turn on or restart) operations, as well as input and output sleep states. In some embodiments, time data for desired milestones (eg boot time for specific hardware) within the boot-up or boot-down processes may also be made available.
    [00023] The presented platform comprises a CPU 102, sensor devices 110 (eg gyroscopes, speakers, cameras, etc.), other devices / interfaces (eg keyboard, pointing device, USB ports, PCI ports, Wireless ifs, etc.) 116, and a graphics processor (GPX) 122, coupled together via one or more buses and/or point-to-point interconnects. The platform also includes a memory 108 (e.g., DRAM) coupled via a memory controller 106 to at least the CPU 102, and this also includes a firmware 104 (e.g., implemented with a non-volatile memory such as a flash memory ) coupled to the CPU 102. The platform further includes a display 126 coupled via a display controller 124 to the GPX 122 and/or the CPU 102. (It should be appreciated that although a single CPU block is shown, the platform can include multiple CPUs and/or processing cores to run one or more OS chains and to run several different tasks. However, for simplicity, a single CPU running an operating system is shown here).
    [00024] The platform further includes a storage unit 114 (e.g., a solid state drive) coupled via a storage unit controller 112 to at least the CPU 102. The storage unit can store data, applications, and one or more operating systems (OS) such as Linux, Windows™, Mac OS™, Android, etc. Firmware 104 includes a BIOS, EFI or other boot/boot software. (Note that the role of the BIOS has changed over time. For example, on some platforms, the BIOS is being replaced by the more complex EFI (Extensible Firmware Interface), but a BIOS for firmware remains in widespread use. FI has been supported in Microsoft Windows™ versions that support GPT, in Linux kernel 2.6.1 and later, and in Mac OS. However, the distinction between BIOS and EFI is rarely made in terminology by the average computer user, making BIOS a generic term for both systems. For simplicity, however, the term "firmware" will generally be used to refer to BIOS, EFI or alternative boot/boot code).
    [00025] Together, the operating system and firmware include software components to implement a PPM 146 (eg, ACPI) interface to the platform. As abstractly represented in the figure, when the platform turns on, after executing the primitive boot code, the CPU retrieves and runs the boot software (firmware space 142) and among other things, at this time it can establish the data structures for the interface of PPM 146. Once the firmware space (eg BIOS, EFI) has initialized, the OS 144 space is then established as the OS boots into the CPU. At this time, PPM modules within the OS can identify various platform features through the PPM 146 interface being established.
    [00026] Figure 2 is a block diagram that abstractly shows a PPM interface to interface between OS power functionality and performance, on the one hand, and the platform hardware, on the other hand. (It should be noted that this diagram is drawn from an ACPI specification, which from now on is used primarily as an example to conveniently present some of the principles taught here. However, the figure has been abstracted and modified to conform to the concepts specific to this description. For example, the more general term: "PPM" is used instead of "ACPI" in some places and instead of "OSPM" within the OS space. It should be appreciated that ACPI is an implementation specific of a PPM interface).
    [00027] Pertinent to the present description, the platform hardware 202 is shown with the CPU 102 and the hardware components (HWC) 206. The HWC units are represented in which their boot times can be tracked by a FPDT of according to some modalities. A HWC 206 can correspond to circuits, logic units, controllers, execution software, etc. specific.
    [00028] The CPU 102, as discussed above, runs the firmware and the OS, thereby establishing the PPM interface 146, the OS 144 space, and the 240 application space. The application space includes APIs 242 for applications run on the platform. The OS 144 space includes the PPM 232 interface unit, the 234 device units, an OS 236 core, and a PPM 238 system, which facilitate OS performance and power management. In the presented modality, a platform control channel (PCC) is implemented by the PPM interface to communicate between the OS PPM functionality and the PPM hardware characteristics.
    [00029] The PPM 146 interface comprises PPM 222 registers, PPM 224 firmware components and PPM 226 tables. The 222 registers can correspond to specific registers, eg dedicated PPM registers in hardware, eg within the CPU or as part of a controller such as a baseboard controller, or to virtual registers created in software. These can also be a restricted part of the hardware interface, described (at least in localization) by the PPM Tables. ACPI, for example, defines a hardware logging interface that an ACPI-compliant OS can use to control core power management and platform hardware performance characteristics, as described in Section 4 of the ACPI 5.0 Specification (the Specification of ACPI Hardware).
    [00030] PPM 224 firmware components include portions of the firmware that correspond to PPM implementations. Typically these are used to implement interfaces for sleep, wake up, some reset operations. Pertinent to this description, among other things, these may also include components for defining PPM data structures and tables, including those used for FPDT structures, and these may also include one or more routines to maintain and/or update data and /or addresses in the tables (Note that some of the ACPI characteristics that correspond to the 224 firmware components are described in Section 5.3, "Namespace", of the ACPI 5.0 Specification).
    [00031] PPM tables, in general, describe the interfaces to the hardware. Some descriptions limit what can be built. For example, some controls may be embedded in fixed register blocks, and the table specifies the register block address. Most descriptions allow hardware to be built in arbitrary ways and can describe sequences of arbitrary operations necessary to make the hardware work. (For the remainder of the description, ACPI tables will be described as examples of suitable PPM table structures. ACPI tables are generally described in Section 5.2 of the ACPI 5.0 Specification).
    [00032] ACPI tables that have "Definition Blocks" can make use of a type of pseudocode language, the interpretation of which can be performed by the OS. That is, OSPM (corresponds to PPM system 238) includes and uses an interpreter that executes the procedures coded in the pseudocode language and stored in the ACPI tables that contain the "Definition Blocks". The pseudocode language, known as ACPI Machine Language (AML), is a compact, tokenized, abstract type of machine language. In some modalities, AML routines can be used to facilitate the acquisition and generation of firmware performance data, as shown below.
    [00033] Figure 3 shows a routine 302 to track firmware performance according to some modalities. In 304, the routine can record the time when the firmware starts. (This can correspond to a Final Reset, as described in Figure 16). On some platforms, the boot firmware may not actually start at or near 0 when the CPU is turned on or reset. This is because other preliminary processing can take place when the CPU is turned on (powered on or reset) before reaching the firmware. Consequently, by recording the time (or timestamp), a routine or user can assess the actual firmware boot time more accurately, that is, when it actually starts and not simply when the CPU turns on. (It should be appreciated that logging a timer or timestamp refers to logging, or marking a unit of time. Usually, a CPU or other platform clock or counter will generate an execution count when the CPU powers up, and so this CPU count or clock can be used to record time, or time unit, as discussed here. For example, with many x86 platforms, an rdtsc command allows a running routine to read the current timestamp counter. it will be appreciated, however, that any suitable clock or counter providing real time, relative time, or its derivation could be used).
    [00034] At 306, as the firmware is booting, it establishes an FPDT structure within the PPM interface. For example, in an ACPI implementation, ACPI might create data structures based on the tables illustrated in Figures 6-16. Running boot firmware can also record designated time milestones such as the starts or ends of hardware component boots, for example, for a better understanding of how long individual hardware components are taking to boot.
    [00035] At 308, the running firmware records the end of firmware boot. In some embodiments, this can happen when the OS loader is launched. At 310, the routine, from the perspective of the running firmware, waits for a sleep mode to be entered. Any suitable sleep mode state could satisfy this condition. In some ACPI implementations, entry into at least one sleep state S3 satisfies sleep mode entry within this context.
    [00036] If a sleep mode must be entered, then at 312, the routine (for example, the firmware FPDT routine) records when the sleep mode entry is initiated and when it is entered. (In some ACPI modalities, this can correspond to SuspendStart and SuspendEnd functions described in Figure 14). The difference between these values may correspond to a time taken for the platform to enter sleep mode. In some embodiments, data along with other FP data (including other FP data relating to sleep mode) can be stored in memory that is reserved for firmware and not changeable by OS space.
    [00037] When sleep mode should end (platform becomes active) then the routine proceeds to 316 where it records the time taken to exit sleep mode. In ACPI implementations this may correspond to a FullResume function described in Figure 14. From here, the routine proceeds back through loop 310, waiting for the next rest event.
    [00038] The general ACPI table structure, and then the specific ACPI FPDT structure will be described. To give hardware vendors flexibility in choosing their implementation, ACPI uses tables to describe system information, features, and methods for controlling these features. These tables list devices, for example devices on the system board or devices that cannot be detected or managed on power using some other hardware standard. These may also list system capabilities such as supported sleep power states, a description of the power plans and clock sources available in the system, batteries, system indicator lights, and so on. This allows OSPM (PPM 238 system in OS space for ACPI) to control system devices without having to know how system controls are implemented.
    [00039] Figure 4 shows a general structure to implement such tables according to some modalities. A Root System Description Pointer (RSDP) 402 structure is located in the system memory address space and is configurable by platform firmware. This structure contains the address of the Extended System Description Table (XSDT) 404, which references other description tables that provide data for OSPM, providing it with knowledge of the implementation and configuration of the base system.
    [00040] System description tables must start with identical headers. The primary purpose of system description tables is to define for OSPM various industry standard implementation details. Such definitions allow various portions of these implementations to be flexible in hardware requirements and design, yet still provide OSPM with the knowledge it needs to control the hardware directly.
    [00041] OSPM finds the Root System Description Table by following the pointer in the RSDP structure. RSDT starts with the signature 'RSDT' followed by a network of physical pointers to other system description tables that provide various information about other patterns defined in the current system. OSPM examines each table for a known signature. Based on the signature, OSPM can then interpret the implementation-specific data within the table.
    [00042] Referring to Figure 5, the Extended System Description Table (XSDT) is further described. This points to other tables in memory. The first table pointed to by the 402 pointer, the XSDT points to the Fixed ACPI Description Table (FADT). The data within this table includes several fixed-length entries that describe the fixed ACPI characteristics of the hardware. The FADT table refers to the Differentiated System Description Table (DSDT), which contains information and descriptions for various system characteristics. The relationship between these tables is shown in Figure 5.
    [00043] When the OS boots during boot, the OSPM finds the RSDP structure. When OSPM finds the structure, it looks for the physical address for the Root System Description Table or Extended System Description Table. The Root System Description Table starts with the signature "RSDT", while the Extended System Description Table starts with the signature "XSDT". These tables contain one or more physical pointers to other system description tables that provide various information about the system. As shown in Figure 5, there must always be a physical address in the Root System Description Table for Fixed ACPI Description Table (FADT).
    [00044] When OSPM follows a physical pointer to another table, it examines each table for a known signature. Based on the signature, OSPM can then interpret the implementation-specific data within the description table.
    [00045] The purpose of the FADT is to define various static system information relating to configuration and power management. The Fixed ACPI Description Table starts with the signature "FACP". The FADT describes the implementation and configuration details of the ACPI hardware registers on the platform.
    [00046] The GPE0_BLK and GPE1_BLK blocks provide the foundation for an interrupt processing model for Control Methods. P_BLK blocks are for controlling processor characteristics. In addition to the ACPI Hardware Register implementation information, the FADT also contains a physical pointer to a data structure known as the Differentiated System Description Table (DSDT), which is encoded in Definition Block format.
    [00047] A Definition Block contains information about the platform's hardware implementation details in the form of data objects arranged in a hierarchical (tree-structured) entity known as the "ACPI namespace", which represents the hardware configuration of the platform . The definition blocks loaded by OSPM combine to form a namespace that represents the platform. Data objects are encoded in a format known as ACPI Machine Language or abbreviated AML. AML-encoded data objects are "evaluated" by an OSPM entity known as the AML interpreter. Its values can be static or dynamic. The AML interpreter's dynamic data object evaluation capability includes support for programmatic evaluation, including accessing address spaces (eg, I/O or memory accesses), calculation, and logical evaluation, to determine the result. Dynamic namespace objects are known as "control methods". OSPM "loads" or "unloads" an entire definition block as a logical unit - adding or removing the associated objects from the namespace. DSDT must be loaded by OSPM at boot time and must not be unloaded. This contains a Definition Block called the Differentiated Definition Block that contains the implementation and configuration information that OSPM can use to perform power management, thermal management, or Plug and Play functionality that goes beyond the information described by the logs. of ACPI hardware.
    [00048] Definition Blocks can either define new system attributes or, in some cases, build previous definitions. A Definition Block can be loaded from the system memory address space. One use of a Definition Block is to describe and distribute platform version changes.
    [00049] Definition Blocks allow wide variations of hardware platform implementations to be described for the ACPI compliant OS while confining the variations to reasonable limits. Definition Blocks allow simple platform implementations to be expressed using few well-defined object names.
    [00050] Some operators perform simple functions and others cover complex functions. The power of the Definition Block comes from its ability to allow these operations to be glued together in numerous modes to provide functionality for OSPM. Operators present are intended to allow many useful hardware designs to be expressed in ACPI, not to allow all hardware designs to be expressed.
    [00051] Figures 6 to 16 show the ACPI FPDT feature table structure. Figure 6 is a table showing the format for Firmware Performance Data Table (FPDT), which provides descriptions and structure for platform boot performance records. (Note that the FPDT is a structure that can, and with ACPI can, include multiple tables that can be organizationally linked together, as described here). The information in these performance logs represents firmware boot performance data relating to specific tasks within a firmware boot process.
    [00052] The ACPI FPDT includes two milestones that are part of most, if not all, platform boot processes, and it provides for these milestones to be registered for basic boot as well as for sleep-relative boot. These milestones are: (1) the end of the CPU reset sequence (the timer value can be noticed at the start of firmware initialization), and (2) transfer to the OS loader. The difference between these two milestones corresponds to a firmware boot time. (Note that in some embodiments, additional milestones, for example when individual hardware components boot within the full firmware boot, may also be included within this framework, and other information is also specified by ACPI as discussed below).
    [00053] (Note that this information represents a set of firmware boot performance data that could be used to track the performance of each phase of UEFI, and could be useful to track impacts resulting from changes due to hardware configuration / In addition, timer values are expressed in nanosecond increments. For example, if a record indicates an event occurred at a timer value of 25678, this means that 25,678 microseconds elapsed from the last reset of the timer measurement).
    [00054] Fig. 7 is a table that shows a structure for recording performance in an FPDT according to ACPI. A performance record includes a sub-header that includes a record type and length, and a data set, which can include a timer. The record layout format is specific to the record type. Thus, records need only be as large as necessary to contain the specific type of data to be transported.
    [00055] The table in Fig. 8 describes the various types of records contained in the FPDT, and their associated Performance Record Type. Note that unless otherwise specified, multiple performance records are allowed in the FPTD for a given type, because some events may be incurred multiple times during the boot process.
    [00056] The table in Fig. 9 describes the various types of runtime records and their associated Runtime Performance Record types. These records are not typically contained in the FPDT table itself; but instead are referenced by their respective pointer records in the FPDT. Pointers can be used to point to, and store records in, a memory space that cannot be changed by the OS.
    [00057] Fig. 10 is a table showing an S3 performance table pointer record. The S3 Performance Table Pointer Register contains a pointer to the S3 Performance Table. The S3 Performance Table itself exists in a memory range described as ACPI AddressRangeReserved in the system memory map. The register pointer can be required entry in the FPDT for any system that supports the S3 state, and the pointer must point to a valid static physical address. Only one of these records will usually be produced.
    [00058] The Firmware Base Boot Performance Pointer Log contains a pointer to the Firmware Base Boot Performance Data Log. The Firmware Base Boot Performance Data Log itself exists in a memory range described as ACPI AddressRangeReserved in the system memory map. The registry pointer is a required entry in the FPDT for any system and the pointer must point to a valid static physical address. Only one of these records will usually be produced.
    [00059] With reference to Figs. 12-14, the S3 Performance Table resides outside the FPDT. This includes a header, defined in Fig. 12, and one or more Performance Records (see, Figures 13 and 14.)
    [00060] Event entries must be initialized to zero during the initial boot sequence, and overwritten during the BIOS S3 (Firmware) reset sequence. The S3 Performance Table should include the Basic S3 Restart Performance Log (Fig. 13). Other entries are optional.
    [00061] Fig. 15 is a table showing a firmware basic boot performance table header. The Firmware Base Boot Performance Table resides outside of the FPDT. This includes a header, defined in Fig. 15, and one or more Performance Records.
    [00062] Fig. 16 is a table showing a basic firmware boot performance data record structure. A firmware basic boot performance data record which contains timer information associated with final OS loader activity as well as data associated with start and fine boot time information.
    [00063] The invention is not limited to the described embodiments, but may be practiced with modifications and alterations within the spirit and scope of the appended claims. It should also be appreciated that in some of the drawings, the signal conducting lines are shown with lines. Some may be thicker, to indicate more constituent signal paths, have a number label, to indicate a number of constituent signal paths, and/or have arrows at one or more ends to indicate the primary information flow direction . This, however, should not be considered in a limiting mode. Instead, such added detail can be used in connection with one or more exemplary modalities to facilitate an easier understanding of a circuit. Any signal lines represented, whether or not having additional information, can actually comprise one or more signals that can be shifted in multiple directions and can be implemented with any suitable type of signal scheme.
    权利要求:
    Claims (20)
    [0001]
    1. Computing platform (100), characterized by the fact that it comprises: a non-volatile memory having a firmware boot program; and a CPU to run the firmware boot program when the CPU is rebooted, the firmware boot program including instructions to create Power Management Interface (PPM) data structures including a performance data table structure (FPDT) to track one or more firmware boot parameters.
    [0002]
    2. Computing platform (100), according to claim 1, characterized in that the firmware boot program comprises instructions, which when executed, record a timer value to indicate a firmware boot start time.
    [0003]
    3. Computing platform (100) according to claim 2, characterized in that the registered firmware boot start time value is used to populate a RestEnd performance record in an Advanced Interface FPDT structure. Configuration and Power (ACPI).
    [0004]
    4. Computing platform (100) according to claim 1, characterized in that the FPDT is to track the firmware boot time when the CPU is rebooted, the firmware boot time to start when the firmware is released.
    [0005]
    5. Computing platform (100), according to claim 1, characterized in that the FPDT is to track a duration of suspension time for the platform to transition from an active state to a resting state.
    [0006]
    6. Computing platform (100), according to claim 5, characterized by the fact that the sleep state is a sleep state of system S3.
    [0007]
    7. Computing platform (100), according to claim 5, characterized in that the duration of the sleep time is based on a start time of sleep when an Operating System (OS) starts the sleep state and a sleep end time when firmware should trigger hardware entry into sleep state.
    [0008]
    8. Computing platform (100), according to claim 1, characterized in that the FPDT is to track a restart time for the platform to transition from an active state to a resting state.
    [0009]
    9. Computing platform (100), according to claim 8, characterized in that the FPDT is to record a full reset value that corresponds to a timer value when the firmware transitions control to a hardware vector for enter the active state.
    [0010]
    10. Computing platform (100), characterized in that it comprises: a first memory storage device having instructions for an operating system (OS) that includes OS Performance and Power Management (PPM) components for an interface of PPM; a second memory storage device having instructions for a firmware boot program including firmware PPM components for a PPM interface, the OS, and the firmware PPM instructions, when executed, to establish a PPM interface between the OS and platform hardware, the PPM interface including a firmware performance data structure to track firmware performance characteristics.
    [0011]
    11. Computing platform (100), according to claim 10, characterized in that it comprises one or more hardware components to be initialized when the firmware boot program executes the initialization of a system, in which the Firmware performance data structure tracks boot times for at least some of the hardware components.
    [0012]
    12. Computing platform (100) according to claim 10, characterized by the fact that the firmware performance data structure is a table of firmware performance data (FPDT) in an Advanced Interface PPM. Configuration and Power (ACPI).
    [0013]
    13. Computing platform (100), according to claim 12, characterized by the fact that the FPDT comprises a performance recording structure.
    [0014]
    14. Computing platform (100), according to claim 12, characterized by the fact that the FPDT comprises a runtime performance record type table.
    [0015]
    15. Computing platform (100), according to claim 12, characterized by the fact that the FPDT comprises an S3 performance table pointer record structure.
    [0016]
    16. Computing platform (100), according to claim 12, characterized by the fact that the FPDT comprises a basic firmware boot performance data logging structure.
    [0017]
    17. Apparatus, characterized in that it comprises: a computing platform (100) having a firmware that includes Advanced Configuration and Power Interface (ACPI) components to build a firmware performance data table (FPDT) structure for an ACPI interface.
    [0018]
    18. Apparatus according to claim 17, characterized in that the FPDT structure includes a performance record structure comprising performance records with firmware performance data.
    [0019]
    19. Apparatus according to claim 17, characterized in that the FPDT comprises a runtime performance record type table.
    [0020]
    20. Apparatus according to claim 17, characterized in that the FPDT comprises a S3 performance table pointer record structure.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112014012398B1|2021-06-15|COMPUTING PLATFORM AND APPARATUS FOR COMPUTING PERFORMANCE AND POWER MANAGEMENT WITH FIRMWARE PERFORMANCE DATA STRUCTURE
    US9081734B2|2015-07-14|Restoring from a legacy OS environment to a UEFI pre-boot environment
    KR20140064788A|2014-05-28|Method and system for building a low power computer system
    BRPI0822765A2|2019-09-10|computer-implemented method for providing hybrid shutdown and quick start processes for a computer system, system for providing hybrid shutdown and quick start processes and a computer readable
    US7975084B1|2011-07-05|Configuring a host computer using a service processor
    US20160026477A1|2016-01-28|Out-of-band retrieval of network interface controller information
    TW201915723A|2019-04-16|Preserving firmware setting during firmware update
    US8370618B1|2013-02-05|Multiple platform support in computer system firmware
    US10474517B2|2019-11-12|Techniques of storing operational states of processes at particular memory locations of an embedded-system device
    JP2020038604A|2020-03-12|Method and system for streamlined server design
    US20190220428A1|2019-07-18|Partitioned interconnect slot for inter-processor operation
    KR101865990B1|2018-07-04|Hiding logical processors from an operating system on a computer
    US10289467B2|2019-05-14|Error coordination message for a blade device having a logical processor in another system firmware domain
    US9781015B2|2017-10-03|Making memory of compute and expansion devices available for use by an operating system
    TW202125232A|2021-07-01|Method and system for indicating bios post status
    US10613850B1|2020-04-07|Performant and secure storage and retrieval of firmware variables
    WO2022040911A1|2022-03-03|Methods and apparatus to perform pseudo-s3 protocol to update firmware and/or activate new firmware with warm reset
    US11106457B1|2021-08-31|Updating firmware runtime components
    US11086758B1|2021-08-10|Identifying firmware functions executed in a call chain prior to the occurrence of an error condition
    US20210286608A1|2021-09-16|Transfer of firmware updates using an in-band interface
    BRPI1004953A2|2013-01-15|Multiple boot manager method
    同族专利:
    公开号 | 公开日
    US9454380B2|2016-09-27|
    US11221857B2|2022-01-11|
    US20170003724A1|2017-01-05|
    US20170147484A1|2017-05-25|
    US20180181407A1|2018-06-28|
    GB2510091A|2014-07-23|
    US20140059337A1|2014-02-27|
    DE112011105867B4|2020-03-19|
    JP6155507B2|2017-07-05|
    US20140258701A1|2014-09-11|
    TW201337537A|2013-09-16|
    TWI502505B|2015-10-01|
    US20140053024A1|2014-02-20|
    TW201335841A|2013-09-01|
    US20130151569A1|2013-06-13|
    TWI518586B|2016-01-21|
    KR20170072953A|2017-06-27|
    WO2013077891A1|2013-05-30|
    IN2014CN02785A|2015-07-03|
    US9594570B2|2017-03-14|
    WO2013078418A1|2013-05-30|
    CN103946765B|2017-11-17|
    US20140059368A1|2014-02-27|
    KR101763102B1|2017-08-04|
    US10732986B2|2020-08-04|
    US10078522B2|2018-09-18|
    BR112014012398A2|2017-06-13|
    JP2015505388A|2015-02-19|
    US10275260B2|2019-04-30|
    US20170147358A1|2017-05-25|
    GB201408838D0|2014-07-02|
    KR101810822B1|2017-12-19|
    US10108433B2|2018-10-23|
    TWI467363B|2015-01-01|
    WO2013078397A1|2013-05-30|
    WO2013078363A1|2013-05-30|
    KR20170013402A|2017-02-06|
    US9535711B2|2017-01-03|
    WO2013078387A1|2013-05-30|
    US20190317773A1|2019-10-17|
    DE112011105867T5|2014-11-06|
    WO2013077890A1|2013-05-30|
    US9442739B2|2016-09-13|
    KR20140082832A|2014-07-02|
    US10514931B2|2019-12-24|
    WO2013077889A1|2013-05-30|
    US9898306B2|2018-02-20|
    US9454379B2|2016-09-27|
    CN103946765A|2014-07-23|
    US20190065211A1|2019-02-28|
    TW201339967A|2013-10-01|
    US20130275737A1|2013-10-17|
    US10007528B2|2018-06-26|
    GB2510091B|2020-05-20|
    US20130283032A1|2013-10-24|
    US20130275796A1|2013-10-17|
    KR101723009B1|2017-04-04|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US4641308A|1984-01-03|1987-02-03|Texas Instruments Incorporated|Method of internal self-test of microprocessor using microcode|
    US4646232A|1984-01-03|1987-02-24|Texas Instruments Incorporated|Microprocessor with integrated CPU, RAM, timer, bus arbiter data for communication system|
    TW282525B|1994-06-17|1996-08-01|Intel Corp|
    US6052793A|1998-06-10|2000-04-18|Dell Usa, L.P.|Wakeup event restoration after power loss|
    EP1172732A4|1999-02-24|2009-08-19|Hitachi Ltd|Computer system and method of handling trouble of computer system|
    US7197548B1|1999-07-20|2007-03-27|Broadcom Corporation|Method and apparatus for verifying connectivity among nodes in a communications network|
    US6732280B1|1999-07-26|2004-05-04|Hewlett-Packard Development Company, L.P.|Computer system performing machine specific tasks before going to a low power state|
    EP1085396A1|1999-09-17|2001-03-21|Hewlett-Packard Company|Operation of trusted state in computing platform|
    US7016060B1|1999-12-08|2006-03-21|International Business Machines Corporation|Method, system, and program for reconfiguring logical printers in a network printing system|
    US6499102B1|1999-12-29|2002-12-24|Intel Corporation|Method of dynamically changing the lowest sleeping state in ACPI|
    US7085944B1|2000-09-30|2006-08-01|Intel Corporation|Power management by transmitting single multiplexed signal to multiple system components to change settings of internal performance registers in response to change in power source|
    US6704877B2|2000-12-29|2004-03-09|Intel Corporation|Dynamically changing the performance of devices in a computer platform|
    US7017060B2|2001-03-19|2006-03-21|Intel Corporation|Power management system that changes processor level if processor utilization crosses threshold over a period that is different for switching up or down|
    US7089430B2|2001-12-21|2006-08-08|Intel Corporation|Managing multiple processor performance states|
    US20030188146A1|2002-03-28|2003-10-02|Hale Robert P.|Method of ordered execution of firmware modules in a pre-memory execution environment|
    US6848057B2|2002-05-28|2005-01-25|Nvidia Corporation|Method and apparatus for providing a decoupled power management state|
    US20040024867A1|2002-06-28|2004-02-05|Openwave Systems Inc.|Method and apparatus for determination of device capabilities on a network|
    US6990576B2|2002-08-07|2006-01-24|Hewlett-Packard Development Company, L.P.|System and method for using a firmware interface table to dynamically load an ACPI SSDT|
    US7698583B2|2002-10-03|2010-04-13|Via Technologies, Inc.|Microprocessor capable of dynamically reducing its power consumption in response to varying operating temperature|
    US7131015B2|2002-11-12|2006-10-31|Arm Limited|Performance level selection in a data processing system using a plurality of performance request calculating algorithms|
    US7219241B2|2002-11-30|2007-05-15|Intel Corporation|Method for managing virtual and actual performance states of logical processors in a multithreaded processor using system management mode|
    US7007160B1|2002-12-03|2006-02-28|Hewlett-Packard Development Company, L.P.|System and method for loading an advanced configuration and power interface original equipment manufacturer description table|
    CN1534863A|2003-01-15|2004-10-06|松下电器产业株式会社|Oscillating circuit|
    US7827283B2|2003-02-19|2010-11-02|International Business Machines Corporation|System for managing and controlling storage access requirements|
    US7502803B2|2003-05-28|2009-03-10|Hewlett-Packard Development Company, L.P.|System and method for generating ACPI machine language tables|
    US7051215B2|2003-06-13|2006-05-23|Intel Corporation|Power management for clustered computing platforms|
    US7752470B2|2003-12-03|2010-07-06|International Business Machines Corporation|Method and system for power management including device controller-based device use evaluation and power-state control|
    US7360103B2|2004-05-21|2008-04-15|Intel Corporation|P-state feedback to operating system with hardware coordination|
    US20050283599A1|2004-06-22|2005-12-22|Zimmerman Toby S|Exposing BIOS information to an ACPI aware operating system|
    WO2006008885A1|2004-07-16|2006-01-26|Brother Kogyo Kabushiki Kaisha|Connection mode control device, connection mode control method, and connection mode control program|
    US7386688B2|2004-07-29|2008-06-10|Hewlett-Packard Development Company, L.P.|Communication among partitioned devices|
    US7594128B2|2004-08-04|2009-09-22|Hewlett-Packard Development Company, L.P.|Systems and methods to determine processor utilization|
    US7565562B2|2004-09-03|2009-07-21|Intel Corporation|Context based power management|
    US7242227B2|2004-11-01|2007-07-10|Texas Instruments Incorporated|Common mode stabilization circuit for differential bus networks|
    US7610497B2|2005-02-01|2009-10-27|Via Technologies, Inc.|Power management system with a bridge logic having analyzers for monitoring data quantity to modify operating clock and voltage of the processor and main memory|
    US7487222B2|2005-03-29|2009-02-03|International Business Machines Corporation|System management architecture for multi-node computer system|
    CN100527089C|2005-04-27|2009-08-12|松下电器产业株式会社|Power controller in information processor|
    US7454639B2|2005-06-30|2008-11-18|Intel Corporation|Various apparatuses and methods for reduced power states in system memory|
    US20070043965A1|2005-08-22|2007-02-22|Intel Corporation|Dynamic memory sizing for power reduction|
    US7562234B2|2005-08-25|2009-07-14|Apple Inc.|Methods and apparatuses for dynamic power control|
    US7516336B2|2005-09-29|2009-04-07|Intel Corporation|System and method for power reduction by sequestering at least one device or partition in a platform from operating system access|
    US7509471B2|2005-10-27|2009-03-24|Sandisk Corporation|Methods for adaptively handling data writes in non-volatile memories|
    US20070136523A1|2005-12-08|2007-06-14|Bonella Randy M|Advanced dynamic disk memory module special operations|
    US7421601B2|2006-02-17|2008-09-02|International Business Machines Corporation|Method and system for controlling power in a chip through a power-performance monitor and control unit|
    US20070260761A1|2006-03-28|2007-11-08|Inventec Corporation|Inter-module data communication control method and system for ACPI and BIOS|
    JP2007272573A|2006-03-31|2007-10-18|Hitachi Ltd|Power consumption reduction memory management method and memory management program|
    US7752468B2|2006-06-06|2010-07-06|Intel Corporation|Predict computing platform memory power utilization|
    US7747881B2|2006-08-14|2010-06-29|Globalfoundries Inc.|System and method for limiting processor performance|
    US20080046546A1|2006-08-18|2008-02-21|Parmar Pankaj N|EFI based mechanism to export platform management capabilities to the OS|
    KR100770703B1|2006-08-30|2007-10-29|삼성전자주식회사|Memory system with power throttling scheme based on power parameter of memory device|
    JP2008109243A|2006-10-24|2008-05-08|Renesas Technology Corp|Semiconductor integrated circuit for rf communication|
    US20080147357A1|2006-12-15|2008-06-19|Iintrinisyc Software International|System and method of assessing performance of a processor|
    US7953996B2|2006-12-18|2011-05-31|Hewlett-Packard Development Company, L.P.|ACPI to firmware interface|
    KR100890152B1|2006-12-22|2009-03-20|매그나칩 반도체 유한회사|Small Size, High Gain, and Low Noise Pixel for CMOS Image Sensors|
    US8302087B2|2007-01-05|2012-10-30|International Business Machines Corporation|Quality assurance in software systems through autonomic reliability, availability and serviceability code generation|
    JP4912174B2|2007-02-07|2012-04-11|株式会社日立製作所|Storage system and storage management method|
    US8448024B2|2007-05-16|2013-05-21|Intel Corporation|Firmware assisted error handling scheme|
    TW200917006A|2007-10-01|2009-04-16|Inventec Corp|Apparatus and method for power management|
    US8250354B2|2007-11-29|2012-08-21|GlobalFoundries, Inc.|Method and apparatus for making a processor sideband interface adhere to secure mode restrictions|
    US20090150696A1|2007-12-10|2009-06-11|Justin Song|Transitioning a processor package to a low power state|
    US8151081B2|2007-12-20|2012-04-03|Intel Corporation|Method, system and apparatus for memory address mapping for sub-socket partitioning|
    US7831816B2|2008-05-30|2010-11-09|Globalfoundries Inc.|Non-destructive sideband reading of processor state information|
    US7912082B2|2008-06-09|2011-03-22|Oracle America, Inc.|Shared virtual network interface|
    US7984286B2|2008-06-25|2011-07-19|Intel Corporation|Apparatus and method for secure boot environment|
    US20090327609A1|2008-06-30|2009-12-31|Bruce Fleming|Performance based cache management|
    US20100153523A1|2008-12-16|2010-06-17|Microsoft Corporation|Scalable interconnection of data center servers using two ports|
    US8458498B2|2008-12-23|2013-06-04|Intel Corporation|Method and apparatus of power management of processor|
    US8601296B2|2008-12-31|2013-12-03|Intel Corporation|Downstream device service latency reporting for power management|
    US8799691B2|2009-01-07|2014-08-05|Hewlett-Packard Development Company, L.P.|Hierarchical power management|
    EP2390786A4|2009-01-26|2012-08-08|Fujitsu Ltd|Information processor provided with configuration change function, system configuration change method, and system configuration change program|
    JP5118074B2|2009-01-27|2013-01-16|日本電信電話株式会社|Optical fiber|
    US8131991B2|2009-02-10|2012-03-06|Sony Corporation|System and method for configuring plural software profiles|
    US8135970B2|2009-03-06|2012-03-13|Via Technologies, Inc.|Microprocessor that performs adaptive power throttling|
    US20100235834A1|2009-03-16|2010-09-16|Faasse Scott P|Providing a management communication channel between a software layer and platform layer for hardware management control|
    US8171319B2|2009-04-16|2012-05-01|International Business Machines Corporation|Managing processor power-performance states|
    US9244797B2|2009-05-29|2016-01-26|Dell Products L.P.|Methods for managing performance states in an information handling system|
    US8490179B2|2009-10-27|2013-07-16|Hewlett-Packard Development Company, L.P.|Computing platform|
    US20110131427A1|2009-12-02|2011-06-02|Jorgenson Joel A|Power management states|
    US20110145555A1|2009-12-15|2011-06-16|International Business Machines Corporation|Controlling Power Management Policies on a Per Partition Basis in a Virtualized Environment|
    US8555091B2|2009-12-23|2013-10-08|Intel Corporation|Dynamic power state determination of a graphics processing unit|
    JP5544878B2|2009-12-25|2014-07-09|富士通株式会社|Failure control device, processor core, arithmetic processing device, information processing device, and simulated failure control method|
    US9310838B2|2010-03-19|2016-04-12|I/O Interconnect, Ltd.|Power management method for switching power mode of a computer system based on detection of a human interface device|
    KR20110114910A|2010-04-14|2011-10-20|삼성전자주식회사|Integarated circuit and power consumption measuring method thereof|
    US8522066B2|2010-06-25|2013-08-27|Intel Corporation|Providing silicon integrated code for a system|
    US8648690B2|2010-07-22|2014-02-11|Oracle International Corporation|System and method for monitoring computer servers and network appliances|
    JP5598144B2|2010-08-04|2014-10-01|ソニー株式会社|Information processing apparatus, power supply control method, and program|
    US8495395B2|2010-09-14|2013-07-23|Advanced Micro Devices|Mechanism for controlling power consumption in a processing node|
    US8812825B2|2011-01-10|2014-08-19|Dell Products L.P.|Methods and systems for managing performance and power utilization of a processor employing a fully multithreaded load threshold|
    US9454197B2|2011-01-28|2016-09-27|Renesas Electronics Corporation|Controller and semiconductor system|
    US8659341B2|2011-05-02|2014-02-25|Analog Devices, Inc.|System and method for level-shifting voltage signals using a dynamic level-shifting architecture|
    US8788777B2|2011-05-06|2014-07-22|Marvell World Trade Ltd.|Memory on-demand, managing power in memory|
    US8966305B2|2011-06-30|2015-02-24|Advanced Micro Devices, Inc.|Managing processor-state transitions|
    US9026815B2|2011-10-27|2015-05-05|Intel Corporation|Controlling operating frequency of a core domain via a non-core domain of a multi-domain processor|
    US9031847B2|2011-11-15|2015-05-12|Microsoft Technology Licensing, Llc|Voice-controlled camera operations|
    WO2013077891A1|2011-11-22|2013-05-30|Intel Corporation|Collaborative processor and system performance and power management|
    US8645797B2|2011-12-12|2014-02-04|Intel Corporation|Injecting a data error into a writeback path to memory|WO2013077891A1|2011-11-22|2013-05-30|Intel Corporation|Collaborative processor and system performance and power management|
    US9026817B2|2012-06-29|2015-05-05|Intel Corporation|Joint optimization of processor frequencies and system sleep states|
    CN104956337B|2013-01-31|2018-01-09|三菱电机株式会社|The control method of computer installation and computer installation|
    US9696785B2|2013-12-28|2017-07-04|Intel Corporation|Electronic device having a controller to enter a low power mode|
    US10514942B2|2014-02-24|2019-12-24|Red Hat Israel, Ltd.|Using linker scripts for loading system configuration tables|
    US9571465B1|2014-09-18|2017-02-14|Amazon Technologies, Inc.|Security verification by message interception and modification|
    KR102261815B1|2014-10-30|2021-06-07|삼성전자주식회사|Data storage device for reducing firmware update time, and data processing system including the same|
    US9720827B2|2014-11-14|2017-08-01|Intel Corporation|Providing multiple memory modes for a processor including internal memory|
    WO2016171671A1|2015-04-21|2016-10-27|Hewlett-Packard Development Company, L.P.|Performance change predictions|
    CN106874176B|2015-12-14|2021-04-27|创新先进技术有限公司|Intelligent test method and device|
    US10180793B2|2017-01-31|2019-01-15|Hewlett Packard Enterprise Development Lp|Performance attributes for memory|
    US11182315B2|2017-02-10|2021-11-23|Intel Corporation|Apparatuses, methods, and systems for hardware control of processor performance levels|
    US10958729B2|2017-05-18|2021-03-23|Intel Corporation|Non-volatile memory express over fabricusing volume management device|
    US10627880B2|2017-05-19|2020-04-21|Dell Products L.P.|Systems and methods for forward compatibility of custom thermal settings|
    KR20190050087A|2017-11-02|2019-05-10|삼성전자주식회사|Semiconductor memory devices, memory systems including the same and methods of operating semiconductor memory devices|
    US10620969B2|2018-03-27|2020-04-14|Intel Corporation|System, apparatus and method for providing hardware feedback information in a processor|
    TWI685751B|2018-04-10|2020-02-21|神雲科技股份有限公司|Error reporting function control method for server device|
    US10795746B2|2018-12-13|2020-10-06|Micron Technology, Inc.|Automated power down based on state of firmware|
    WO2021011577A1|2019-07-15|2021-01-21|Intel Corporation|Dynamic energy performance preference based on workloads using an adaptive algorithm|
    US11157329B2|2019-07-26|2021-10-26|Intel Corporation|Technology for managing per-core performance states|
    TWI726405B|2019-09-04|2021-05-01|神雲科技股份有限公司|Boot procedure debugging system, host and method thereof|
    US20220057945A1|2020-08-20|2022-02-24|Micron Technology, Inc.|Security techniques for low power mode of memory device|
    CN112256327A|2020-11-01|2021-01-22|屈军军|Miniature electronic mechanical device|
    法律状态:
    2018-12-04| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|
    2019-11-26| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|
    2021-05-04| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|
    2021-06-01| B350| Update of information on the portal [chapter 15.35 patent gazette]|
    2021-06-15| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 21/11/2012, OBSERVADAS AS CONDICOES LEGAIS. |
    优先权:
    申请号 | 申请日 | 专利标题
    US201161563030P| true| 2011-11-22|2011-11-22|
    US61/563,030|2011-11-22|
    PCT/US2012/066364|WO2013078387A1|2011-11-22|2012-11-21|Computing performance and power management with firmware performance data structure|
    [返回顶部]